Section 3.9.3.3
Scene File Gamma

The image file gamma problem itself is just a result of how scenes themselves are generated in POV-Ray. When you start out with a new scene and are placing light sources, and adjusting surface textures and colors, you generally make several attempts before the lighting is how you like it. How you choose these settings depends upon the preview image, or the image file stored to disk, which in turn is dependent upon the overall gamma of the display hardware being used.

This means that as the artist, you are doing gamma correction in the POV-Ray scene file for your particular hardware. This scene file will generate an image file that is also gamma corrected for your hardware, and will display correctly on systems similar to your own. However, when this scene is rendered on another platform, it may be too bright or too dim, regardless of the output file format used. Rather than have you change all the scene files to have a single fixed gamma value (heaven forbid!), POV-Ray 3.0 allows you to specify in the scene file the Display_Gamma of the system that the scene was created on.

The assumed_gamma global setting, in conjunction with the Display_Gamma INI setting lets POV-Ray know how to do gamma correction on a given scene so that the preview and output image files will appear the correct brightness on any system. Since the gamma correction is done internally to POV-Ray, it will produce output image files that are the correct brightness for the current display, regardless of what output format is used. As well, since the gamma correction is performed in the high-precision data format the POV-Ray uses internally, it produces better results than gamma correction done after the file is written to disk.

Although you may not notice any difference in the output on your system with and without an assumed_gamma setting, the {HIW/}assumed_gamma is important if the scene is ever rendered on another platform.

Section 3.9.4
HF_Gray_16

The hf_gray_16 setting is useful when using POV-Ray to generate heightfields for use in other POV-Ray scenes. The syntax is...

global_setting { hf_gray_16 BOOLEAN }

The boolean values turns the option on or off. If the keyword is specified without the boolean value then the option is turned on. If hf_gray_16 is not specified in any global_settings statement in the entire scene then the default is off.

When hf_gray_16 is on, the output file will be in the form of a heightfield, with the height at any point being dependent on the brightness of the pixel. The brightness of a pixel is calculated in the same way that color images are converted to grayscale images, as follows: 

  height = 0.3 * red + 0.59 * green + 0.11 * blue

Setting the hf_gray_16 option will cause the preview display, if used, to be in a grayscale rather than color. This is to allow you to see how the heightfield will look, because some file formats store heightfields in a way that is difficult to understand afterwards. See section "Height Field" for a description of how POV-Ray heightfields are stored for each file type.

Section 3.9.5
Irid_Wavelength

Iridescence calculations depend upon the dominant wavelengths of the primary colors of red, green and blue light. You may adjust the values using the global setting irid_wavelength as follows...

global_settings { irid_wavelength COLOR }

The default value is rgb<0.25,0.18,0.14> and any filter or transmit values are ignored. These values are proportional to the wavelength of light but they represent no real world units.

In general, the default values should prove adequate, but we provide this option as a means to experiment with other values.

Section 3.9.6
Max_Trace_Level

In scenes with many reflective and transparent surfaces, POV-Ray can get bogged down tracing multiple reflections and refractions that contribute very little to the color of a particular pixel. The global setting max_trace_level defines the maximum number of recursive levels that POV-Ray will trace a ray.

global_settings { max_trace_level INTEGER }

This is used when a ray is reflected or is passing through a transparent object and when shadow rays are cast. When a ray hits a reflective surface, it spawns another ray to see what that point reflects, that's trace level 1. If it hits another reflective surface, then another ray is spawned and it goes to trace level 2. The maximum level by default is 5.

One speed enhancement added to POV-Ray in version 3.0 was Adaptive Depth Control , or ADC. Each time a new ray is spawned as a result of reflection or refraction, its contribution to the overall color of the pixel is reduced by the amount of reflection or the filter value of the refractive surface. At some point, this contribution can be considered to be insignificant, and there is no point in tracing any more rays. Adaptive depth control is what tracks this contribution and makes the decision of when to bail out. On scenes that use a lot of partially reflective or refractive surfaces, this can result in a considerable reduction in the number of rays fired and makes it "safer" to use much higher max_trace_level values.

This reduction in color contribution is a result of scaling by the reflection amount and/or the filter values of each surface, so a perfect mirror or perfectly clear surface will not be optimizable by ADC. You can see the results of ADC by watching the "Rays Saved" and "Highest Trace Level" displays on the statistics screen.

The point at which a ray's contribution is considered insignificant is controlled by the adc_bailout value. The default adc_bailout is 1/255, or approximately 0.0039, since a change smaller than that could not be visible in a 24 bit image. Generally this setting is perfectly adequate, and should be left alone. Setting adc_bailout to 0 will disable ADC, relying completely on max_trace_level to set an upper limit on the number of rays spawned.

If max trace level is reached before a non-reflecting surface is found, and if ADC hasn't allowed an early exit from the ray tree, then the color is returned as black. Raise max_trace_level if you see black in a reflective surface where there should be a color.

The other symptom you could see is with transparent objects. For instance, try making a union of concentric spheres with a clear texture on them. Make ten of them in the union with radius's from 1-10 then render the Scene. The image will show the first few spheres correctly, then black. This is because a new level is used every time you pass through a transparent surface. Raise max_trace_level to fix this problem. For example:

Note: Raising max_trace_level will use more memory and time and it could cause the program to crash with a stack overflow error, although ADC will alleviate this to a large extent. Values for max_trace_level are not restricted, so it can be set to any number as long as you have the time and memory. However, increasing its setting does not necessarily equate to increased image quality unless such depths are really needed by the scene.

Section 3.9.7
Max_Intersections

POV-Ray uses a set of internal stacks to collect ray/object intersection points. The usual maximum number of entries in these "I-Stacks" is 64. Complex scenes may cause these stacks to overflow. POV-Ray doesn't stop but it may incorrectly render your scene. When POV-Ray finishes rendering, a number of statistics are displayed. If you see "I-Stack Overflows" reported in the statistics, you should increase the stack size. Add a global setting to your scene as follows:

global_settings { max_intersections INTEGER }

If the "I-Stack Overflows" remain, increase this value until they stop.

Section 3.9.8
Number_Of_Waves

The wave and ripples pattern are generated by summing a series of waves, each with a slightly different center and size. By default, ten waves are summed, but this amount can be globally controlled by changing the number_of_waves setting.

global_settings { number_of_waves INTEGER }

Changing this value affects both waves and ripples alike on all patterns in the scene.

Section 3.9.9
Radiosity

Radiosity is an extra calculation that more realistically computes the diffuse interreflection of light. This diffuse reflection can be seen if you place a white chair in a room full of blue carpet, blue walls, and blue curtains, the chair will pick up a blue tint from light reflecting off of other parts of the room. Also notice that the shadowed areas of your surroundings are not totally dark even if no light source shines directly on the surface. Diffuse light reflecting off of other objects fills in the shadows. Typically ray tracing uses a trick called "ambient" light to simulate such effects but it is not very accurate.

Radiosity is more accurate than simplistic ambient light but it takes much longer to compute. For this reason, POV-Ray does not use radiosity by default. Radiosity is turned on using Quality=10 or Quality=11 options in an INI file or +q10 or +q11 command line switch. The default quality is 9 and uses no radiosity. A value of 10 uses radiosity but does not compute halos. Quality 11 uses radiosity and halos. See "Quality Settings" for details.

The following sections describes how radiosity works, how to control it with various global settings and tips on trading quality vs. speed.

Section 3.9.9.1
How Radiosity Works

The problem of ray tracing is to figure out what the light level is at each point that you can see in a scene. Traditionally, in ray tracing, this is broken into the sum of these components:

-Diffuse, the effect that makes the side of things facing the light brighter;
-Specular, the effect that makes shiny things have dings or sparkles on them;
-Reflection, the effect that mirrors give; and
-Ambient, the general all-over light level that any scene has, which keeps things in shadow from being pure black.

POV's radiosity system, based on a method by Greg Ward, provides a way to replace the last term - the constant ambient light value - with a light level which is based on what surfaces are nearby, and how bright in turn they are.

The first thing you might notice about this definition is that it is circular: the light of everything is dependent on everything else, and vice versa. This is true in real life, but in the world of ray tracing, we can make an approximation. The approximation that is used is: the objects you are looking at have their 'ambient' values calculated for you, by checking the other objects nearby. When those objects are checked during this process, however, a traditional constant ambient term is used.

How does POV calculate the ambient term for each point? By sending out more rays, in many different directions, and averaging the results. A typical point might use 200 or more rays to calculate its ambient light level correctly.

Now, this sounds like it would make the ray tracer 200 times slower. This is true, except that the software takes advantage of the fact that ambient light levels change quite slowly. (Remember, shadows are calculated separately, so sharp shadow edges are not a problem). Therefore, these extra rays are sent out only "once in a while" (about 1 time in 50), then these calculated values are saved and reused for nearby pixels in the image when possible.

This process of saving and reusing values is what causes the need for a variety of tuning parameters, so you can get the scene to look just the way you want.

Section 3.9.9.2
Adjusting Radiosity

As described earlier, radiosity is turned on by using a quality level of 10 or 11, however radiosity has many parameters that are specified in a radiosity {...} statement inside a global_settings {...} statement as follows:

global_settings { radiosity { brightness FLOAT count INTEGER distance_maximum FLOAT error_bound FLOAT gray_threshold FLOAT low_error_factor FLOAT minimum_reuse FLOAT nearest_count INTEGER recursion_limit INTEGER } }

Each item is optional and may appear in and order. If an item is specified more than once, the last setting overrides previous values. Details on each item is given in the following sections.

Section 3.9.9.2.1
brightness

This is the degree to which ambient values are brightened before being returned upwards to the rest of the system. If an object is red <1, 0, 0>, with an ambient value of 0.3, then in normal situations a red component of 0.3 will be added in. With radiosity on, assume it was surrounded by an object of color grey60 <0.6, 0.6, 0.6>. The average color returned by the gathering process will be the same. This will be multiplied by the texture's ambient weight value of 0.3, returning <0.18, 0.18, 0.18>. This is much darker than the 0.3 which would be added in normally. Therefore, all returned values are brightened by the inverse of the average of the calculated values, so the average ambient added in does not change. Some will be higher than specified (higher than 0.3 in this example), and some will be lower, but the overall scene brightness will be unchanged.

The default value is 3.3.

Section 3.9.9.2.2
count

The number of rays that are sent out whenever a new radiosity value has to be calculated. Values of 100-150 make most scenes look good. Higher values might be needed for scenes with high contrast between light levels, or small patches of light causing the illumination. This would be used only for a final rendering on an image, since it is very compute intensive. Since most scenes calculate the ambient value at 1% to 2% of pixels, as a rough estimate, your rendering will take 1% to 2% of this number times as long. If you set it to 300, your rendering might take 3 to 6 times as long to complete (1% to 2% times 300).

When this value is too low, the light level will tend to look a little bit blotchy, as if the surfaces you're looking at were slightly warped. If this is not important to your scene (as in the case that you have a bump map, or if you have a strong texture), then by all means use a lower number.

The default value is 100.

Section 3.9.9.2.3
distance_maximum

This is the only tuning value that depends upon the size of the objects in the scene. This one must be set for scenes to render properly... the rest can be ignored for a first try. It is difficult to describe the meaning simply, but it sets the distance in model units from a sample at which the error is guaranteed to hit 100% (Radiosity_Error_Bound >= 1): no samples are reused at a distance larger than this from their original calculation point.

So, imagine an apple at the left edge of a table. The goal is to make sure that samples on the surface of the table at the right are not used too close to the apple, and definitely not underneath the apple. If you had enough rays, there wouldn't be a problem, since one of them would be guaranteed to hit the apple and set the reuse radius properly for you. In practice, you must limit this.

I use this technique: which object in your scene might have this problem: (a small object on a larger flatter surface, that you want good ambient light near). Now, how far from this would you have to get to be sure that one of your rays had a good chance of hitting it? In the apple-on-the-table example, assuming I used one POV-Ray unit as one inch, I might use 30 inches. A theoretically sound way (when you are running lots of rays) is the distance at which this object's top is 5 degrees above the horizon of the sample point you are considering. This corresponds to about 11 times the height of the object. So, for a 3-inch apple, 33 inches makes some sense. For good behavior under and around a 1/3 inch pea, use 3 inches etc. Another VERY rough estimate is one third the distance from your eye position to the point you are looking at. The reasoning is that you are probably no more than 90 inches from the apple on the table, if you care about the shading underneath it.

The default value is 0.

Next Section
Table Of Contents